Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol (IP) over all kinds of links. However, because of the fact that the headers of the IP protocols are rather large, it is not always a simple task to make this come true for narrow band links, for example wireless cellular links. As an example, consider ordinary speech data transported by the protocols (IP, UDP, RTP) used for Voice-over-IP (VoIP), where the header may represent about 70% of the packet—resulting in a very inefficient usage of the link.
The term header compression (HC) (defined further below) comprises the art of minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. The techniques in general have a more than ten-year-old history within the Internet community; several commonly used protocols exist such as Van Jacobson (VJ), IP Header Compression (IPHC) and compressed real-time transport protocol (CRTP). Header compression takes advantage of the fact that some fields in the headers are not changing within a flow, or change with small and/or predictable values. Header compression schemes make use of these characteristics and send static information only initially, while changing fields are sent with their absolute values or as differences from packet to packet. Completely random information has to be sent without any compression at all.
Header compression is thus an important component to make IP services over wireless, such as voice and video services, economically feasible. Header compression solutions have been developed by the Robust Header Compression (ROHC) Working Group of the IETF (Internet Engineering Task Force) to improve the efficiency of such services.
Other optimizations, such as other types of compression, may also be used to further increase the performance of bandwidth-limited systems. These include payload compression, signalling compression, header removal and regeneration, and header compression. Many of these compression schemes may be designed to make use of a compression and/or decompression context.
The evolution and design using new architectural models tend to move the optimization functions closer to the air interface. For example, in System Architecture Evolution/Long Term Evolution (SAE/LTE) systems the header compression function is located in the enhanced Node B (eNB). Other systems have header compression function in e.g. the Core Network (CN) or in the Radio Network Controller (RNC).
In most systems, a mobility event that changes the node that performs the function providing the optimization (e.g. header compression) normally requires that this function be restarted. In some cases, such as defined in 3GPP specification (RRC signalling), relocation of the context for these functions may be supported. Relocation of the context (i.e. the state used by the optimization function), when possible, helps the function to maintain a certain level of efficiency and normally removes the need to restart the entire procedure of establishing the context used by the function.
Robust Header Compression (ROHC)
Header compression is often characterized as the interaction of a compressor with a decompressor state machine, which maintains some state information related to the flow(s) being compressed in a context (see definitions below).
ROHC is an extensible framework for which profiles for compression of various protocols may be defined. For real-time multimedia services (e.g. voice, video), the application data is transported end-to-end within an IP/UDP/RTP stream. Header compression of IP/UDP/RTP is defined by the ROHC profile 0x000 (ROHC RTP) and by RoHCv2 profile 0x0101, and is applicable for Voice-over-IP (VoIP) services among others.
The ROHC header compression scheme has been designed to efficiently compress the headers over an arbitrary link layer. Except for negotiation, ROHC profiles only requires Framing and error detection to be provided by the link layer, while all other functionality is handled by the ROHC scheme itself.
A number of ROHC profiles have been defined for compression of:
No compression, all IP stack combinationsprofile 0x0000,IP/UDP/RTP headersprofile 0x0001, 0x0101,profile 0x0005, 0x0105,IP/UDP headersprofile 0x0002, 0x0102,IP/ESP headersprofile 0x0003, 0x0103,IP-only headersprofile 0x0004; 0x0104,IP/TCP headersprofile 0x0006,IP/UDP-Lite/RTP headersprofile 0x0007, 0x0107,IP/UDP-Lite headersprofile 0x0008, 0x0108.
Note that the profile that does not compress (0x0000) is for IP traffic that cannot be compressed (no profile for the type of header combination, or lack of resources for [de]compression) but that should co-exist with compressed flows over the RoHC channel. For such traffic, the IP-only profile may be used if available resources allows.
Header Compression State Machines and Context Synchronization
One can usually realize a header compression scheme (such as a ROHC Profile) as a state machine and the challenging task is to keep the compressor and decompressor states, called contexts, consistent with each other, while keeping the header overhead as low as possible. There is one state machine for the compressor, and one state machine for the decompressor. The compressor state machine directly impacts the level of compression efficiency, as it is an important part of the logic controlling the choice of compressed packet type to be sent; the purpose of the decompressor state machine is mainly to provide the logic for feedback (if applicable) and to identify the packet types for which decompression may be attempted.
Packet Types and Context Updates
A packet that provides the means for the decompressor to verify successful decompression is a context-updating packet. Because decompression can be verified, this type of packet can update the context. For ROHC, context-updating packet types carry a Cyclic Redundancy Code (CRC) within their format; this is a checksum calculated over the original uncompressed header. This CRC is used to verify successful decompression of each packet; when successful, the context can be updated.
A packet that relies on other means to guarantee successful decompression—i.e. a packet format does not provide the means for the decompressor to verify successful decompression, and that only carries the information necessary for the decompression itself, is a self-contained packet. These packets do not update the context.
Modes of Operation
The ROHC profiles defined in: Carsten Bormann, et al. RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed. IETF RFC 3095, April 2001; Jonsson, L. and G. Pelletier, RObust Header Compression (ROHC): A compression profile for IP, IETF RFC 3843, June 2004; and, Pelletier, G., RObust Header Compression (ROHC): Profiles for UDP-Lite, IETF RFC 4019, April 2005 all support three different modes of operation. In short, for a specific context, the mode controls the actions and the logic to perform as well as the packet types to use during different states of the header compression operation. Packet types and formats that are allowed may vary from one mode to the other. The Unidirectional mode (U-mode) is used at the beginning of any ROHC compression before any transition to other modes may occur. The Bidirectional Optimistic mode (O-mode) aims to maximize the compression efficiency and sparse usage of the feedback channel. The Bidirectional Reliable mode (R-mode) aims to maximize robustness against loss propagation and context damage propagation. Each mode of operation has different properties in terms of compression efficiency, robustness and processing complexity.
In U-mode, packets are sent from compressor to decompressor only; this mode is thus usable over links where a return path from decompressor to compressor is either not desired or not available, and periodical refreshes are used in this mode. The U-mode is particularly applicable to broadcast or multicast channels.
The O-mode is similar to the U-mode, with the difference that a feedback channel is used to send error recovery requests and (optionally) acknowledgements of significant context updates from the decompressor to compressor.
Note that for most ROHC profiles, the U-mode and the O-mode are often indistinctly referred to using the term U/O-mode. This is because the U-mode and the O-mode have rather similar characteristics, such as an identical set of packets formats for both modes as well as a similar logic to perform context updates. This logic is called the optimistic approach, and provides robustness against packet losses for the context update procedure in U/O-mode.
The R-mode differs significantly from the two other modes. In particular, the R-mode uses a few different packet types only understood and useful in this mode. However, the R-mode differs mainly by making a more extensive usage of the feedback channel and it uses a stricter logic for performing context updates. This logic is based on the secure reference principle, and provides robustness against packet losses for the context update procedure in R-mode.
Robustness Principles in Robust Header Compression—Optimistic Approach
A header compressor may use the optimistic approach to reduce header overhead when performing context updates. The compressor normally repeats the same update until it is fairly confident that the decompressor has successfully received the information. The number of consecutive packets needed to obtain this confidence is typically open to implementations, and this number is normally related to the packet loss characteristics of the link where header compression is used. All the packet types used with the optimistic approach are context updating.
The compressor normally updates its compression context for each packet that it sends.
The header decompressor normally updates its context after verifying the outcome of the decompression, using the CRC carried within the compressed header (always present in the packet format when operating using the optimistic approach).
Robustness Principles in Robust Header Compression—Secure Reference Principle
A header compressor may use the secure reference principle to ensure that context synchronization between compressor and decompressor cannot be lost due to packet losses. The compressor obtains its confidence that the decompressor has successfully updated the context from a context-updating packet based on acknowledgements received by the decompressor. However, most packet types used with the secure reference principle are self-contained and thus not meant to update the context.
The compressor normally updates its compression context only after receiving acknowledgements from the decompressor for a context updating packet (identified using the MSN in the feedback message).
The decompressor normally updates its context after verifying the outcome of the decompression, using the CRC carried within the compressed header (when present in the packet format, not always true when operating using the secure reference principle). Subject to rate limitation, the decompressor normally acknowledges the update to the compressor.
Current Status of RoHC
The “simplified ROHC framework”, or rather the specification of the ROHC framework as an independent document, is published as IETF RFC4095.
The RoHCv2 profiles currently being developed handle out-of-order delivery between compression endpoints, among other improvements.
Recent Trends and Evolutions in Network Architectures
In GSM/EDGE systems, the Gateway GPRS Support Node (GGSN) normally hosts the header compression function.
In the UTRAN architecture, the Radio Network Control (RNC) function hosts the header compression function.
In contrast, the SAE/LTE architecture does not have a RNC. Originally, the architecture specified that the header compression function be located in the PDCP in the Access Gateway (aGW), but later the PDCP function was moved to the eNB. The impact of this decision is that mobility events, from the header compression perspective, will be more frequent than if located in the aGW. Restarting compression requires that a number of uncompressed headers are sent; this may not be sufficiently efficient. More advanced mechanisms, such as relocation of the compression context, may be required.
The concept of context relocation for header compression is not novel. There exist a number of prior art to optionally support context relocation in UTRAN. However, a compression context is not simply a matter of transferring some data from one point to another; it is often believed that it is, for example, sufficient to transfer one IP header to account for the entire transfer of the compression context. What type of data, under what format and how to have the relocation process interact with the header compression algorithm is a very complex issue, one that a close analysis of prior art reveals has not been properly addressed.
One prior art approach is shown in U.S. Pat. No. 6,300,887, which discloses a method of relocating of header compression/decompression functions between a plurality of network entities and mobile compressors and/or mobile decompressors. The method relies on a secure reference, relies on absolute decompressor/compressor context synchronization, requires a (explicit or waited for) specific context synchronization event between compressor and decompressor (e.g. Decompressor feedback with ack and context ID/SN), depends on a particular state of validity for the context (all or partial) at the time of relocation, and, is not applicable generally to header compression algorithms that constantly update their context (e.g. “RoHC U/O-mode” type of operation), only to R-mode. Further:
All information exchange is dependent on the state of the flows at time of relocation: a context cannot be relocated                unless a packet is available, AND        unless feedback channel is active, AND        unless the context is valid        
It focus only on synchronization between compressor and decompressor contexts
No compression is possible in source AFTER the context has been relocated (hard handoff).
Another prior art approach is shown in US-2002091860 A1, which discloses a method of relocating the header compression context in a packet network which transmits packets having compressed headers. The relocation is based on stopping the updating of the context by:                decompressor stops sending feedback        compressor send uncompressed packets when relocation starts        compressor ignores feedback received by decompressor        
Thus, the state-of-the-art requires:                compression in the source node to be stopped, so that the context is frozen in a synchronized manner between source compressor and target compressor for the downlink (or decompressors for uplink, respectively); i.e. the synchronized aspect of the procedure focuses on synchronizing the exchange of context information in the Radio Access Network (RAN) by first stopping compression;        the source for relocation to have absolute confidence in the state of the context in the UE, i.e. it is based on a pre-condition that only a context that has been acknowledged can be relocated, which may not always be timely.        
The impact of the above characteristics of the state-of-the-art solution(s) is that the interruption time during a mobility event cannot be minimized, and as a consequence of stopping compression is that no packets can be transmitted from the source node. Relocation may not be possible either without some additional delay for preparing the context, and waiting for acknowledgement from the decompressor.
There is today no working solution that allows a context relocation mechanism to have the following properties:                to allow the source node (from where a context is taken) to continue compression and transmitting packets even after the context information being relocated is extracted and sent to the target node (i.e. during the mobility event);        to allow the target node to resume compression in the most efficient ratio from the first packet that it starts to compress after having received the context form the source node.        to relocate a context in an interoperable manner, i.e. relocation of a context based on a compression algorithm that does not rely strictly on acknowledgements and on a secure reference (algorithms that relies on the optimistic approach);        to allow the relocation process to start at any time during the lifetime of a compression context.        
The main problem addressed by the invention proposed herein is how to properly relocate a header compression context during mobility event, to improve the spectral efficiency of the handover procedure and minimizing interruption time.
Further problems addressed by the invention are: to make context relocation possible for header compression algorithms that are not strictly based on acknowledgements (and on a secure reference); to allow the source node to continue compressing and transmitting packets even under the mobility event, to allow the eNB to either start relocation early or to empty its queues and/or complete any pending transmissions; and, to allow starting the relocation procedure at any arbitrary time, without involving the mobile terminal.
Thus, there is need for methods and apparatuses overcoming at least one of the above mentioned problems.